4.1.1. Principii de urmat în dezvoltarea interfeţelor grafice 


O interfaţă grafică bine proiectată trebuie să respecte următoarele principii:: 
- controlul aplicaţiei de către utilizator; 
- manipularea directă a informaţiilor; 
- consistență; 
- toleranţă la greşelile utilizatorului; 
- asocierea de "replici" pentru comenzile unei aplicaţii; 
- estetică; 
- claritate; 
- simplitate. 


Controlul aplicaţiei de către utilizator 
Conform primului principiu enunțat, este foarte important ca utilizatorul să simtă 
că el este cel care controlează aplicaţia şi nu invers, în ai doilea rând, utilizatorul 
trebuie să aibă posibilitatea să personalizeze mediul de iucru, conform preferințelor 
sale. Utilizatorul trebuie să fie acela care iniţiază acţiunile; ei trebuie să aibă un rol 
activ şi nu reactiv. Există şi procese care pot fi automatizate, dar derularea lor 
trebuie să se facă sub controlul utilizatorului (la apariţia unor cazuri 
excepţionale utilizatorul trebuie să decidă acţiunea ce va fi executată). Pentru a 
putea răspunde acestui principiu aplicaţia trebuie: 
(a)să fie interactivă (trebuie să ofere întotdeuana un rezultat vizual în urma 
unei acţiuni a utilizatorului) 
(b)să răspundă la fiecare acţiune a utilizatorului 
(c)să fie flexibilă. 
Manipularea directă a informaţiilor 
Conform acestui principiu, utilizatorul trebuie să poată manipula informaţiile întro 
manieră familiară, indiferent de modul în care acestea sunt reprezentate intern la 
nivelul soft-ului-applicaţie. Astfel, utilizatorul poate constata direct relaţia cauză- 
efect între acţiunea sa efectuată prin intermediul interfeţei şi rezultatul acesteia 
(modul în care programul reacţionează la acţiunea sa). Fie că mută un obiect sau se 
deplasează în cadrul unui document, utilizatorul trebuie să vadă modul în care 
acţiunea sa afectează obiectele existente pe ecran. Vizibilitatea informaţiilor şi a 
opţiunilor reduc supraîncărcarea mentală a utilizatorilor. Pentru satisfacerea 
acestei cerinţe, interfaţa trebuie să ofere utilizatorului o manieră directă şi intuitivă 
de operare. 


1 Principii de proiectare a interfeţelor grafice utilizator, în PC Report, nr. 51/1996, p. 26 


Utilizatorii recunosc mai uşor o comandă sau un instrument de lucru dacă le 
asociază cu o imagine sau un simbol. De aceea, în cadrul interfeţelor grafice se 
utilizează metaforele. Acestea facilitează învăţarea şi exploatarea unei aplicaţii, 
permiţând utilizatorilor să-şi transfere cunoştinţele şi experienţa. Metaforele sunt 
deosebit de utile, deoarece utilizatorii rețin mai uşor un înţeles sau o semnificaţie 
ataşate unui obiect familiar, decât ar reţine numele unei comenzi. Când se 
utilizează o metaforă, nu este neapărat necesar ca implementarea în cadrul 
aplicaţiei să fie limitată de corespondentul său din lumea reală. De exemplu, un 
folder (dosar) din Windows, spre deosebire de corespondentul său real, poate 
organiza nu doar documente sau aplicaţii, ci şi echipamente (calculatoare, 
imprimante) sau alte foldere. Motivul folosirii metaforelor într-o interfaţă este 
construirea unui "pod cognitiv”. 

Consistenţa 

Principiul consistenţei cere ca interfaţa să fie familiară şi predictibilă, oferind 
utilizatorului sentimentul de stabilitate. Astfel, indiferent de opţiunile pe care le 
selectează la un moment dat, rezultatul obţinut (o fereastră sau un mesaj de 
atenţionare) trebuie să furnizeze o reprezentare grafică familiară, cu care 
utilizatorul s-a obişnuit deja în cadrul activităţilor zilnice pe care le desfăşoară. 
Consistenţa permite utilizatorilor să transfere cunoştinţele existente în procese noi 
şi să înveţe mai rapid aplicaţiile noi. Consistenţa este citată ca fiind cea mai 
importantă în obţinerea unei interfeţe de calitate. Dacă este asigurată, consistenţa 
îl va sprijini pe utilizator în a-şi construi un model mental adecvat al modului de 
funcţionare al aplicaţiei, ceea ce înseamnă costuri de instruire şi suport post- 
instalare mai scăzute. 

lată câteva obiective pe care programatorul trebuie să le urmărească în 
dezvoltarea interfeţelor grafice pentru a asigura consistenţă la nivelul aplicaţiei: 

- un dublu clic într-o listă anume, poate declanşa o anumită acţiune. Ar fi de 
dorit să se producă aceeaşi acţiune (un acelaşi tip de rezultat) atunci când 
se efectuează dublu clic într-o altă listă din aplicaţie. 

- Butoanele trebuie plasate în locuri "strategice", locuri ce trebuiesc 
păstrate pe parcursul tuturor formularelor aplicaţiei 

- Textul, sau imaginea, afişată de butoane trebuie să fie acelaşi pentru 
butoanele care produc rezultate similare (adăugarea unor date noi, salvarea 
datelor modificate, etc.) 

- Organizarea componentelor de editare a datelor (căsuțe de text, liste de 
opţiuni) trebuie să fie aceeaşi în toate ferestrele ce furnizează acces la 
date. 


Schema de culori utilizată trebuie să fie şi ea consistentă (dacă utilizăm 
aceeaşi culoare pentru două obiecte, între ele ar trebui să existe o legătură 


). 


Consistenţa trebuie asigurată în toate aspectele interfeței: 


numele comenzilor - comenzi similare în aplicații diferite să aibă acelaşi 
nume, pentru a folosi cunoştinţele pe care le au utilizatorii de la 
aplicațiile precedente (majoritatea aplicațiilor folosesc 
pentru deschiderea unui fişier comanda Open); 

prezentarea vizuală a aplicaţiei - comenzile similare din aplicaţii diferite 
trebuie să fie apelabile prin aceleaşi elemente vizuale (de exemplu, 
salvarea unui fişier se face în majoritat:ea aplicaţiilor prin clic pe butonul 
care are stilizată o dischetă); 

comportamentul operațional al aplicaţiei - operaţiile similare trebuie să 
aibă o interfaţă vizuală identică sau măcar asemănătoare, iar cererea de 
informaţii suplimentare pentru realizarea unei operaţiuni trebuie făcută 
utilizând elemente de interfaţă comune operaţiunilor (de exemplu, 
operaţiunile de acces la fişiere - citire sau salvare - ar trebui să 
deschidă casete de dialog asemănătoare). 


Pentru asigurarea consistenţei trebuie avute în vedere următoarele aspecte ale 


acesteia: 


consistenţa în cadrul aplicaţiei. Prezentarea funcţiilor comune 
trebuie să se facă folosind un ansamblu consistent de comenzi şi/sau 
interfeţe vizuale. Implementarea unei comenzi "copy" care într-un caz 
generează o operaţie imediată, iar în alt caz afişează o fereastă de 
dialog pentru introducerea unei destinaţii este un exemplu de 
inconsistenţă. Proiectantul trebuie să folosească aceleaşi comenzi pentru 
operaţii care utilizatorului îi par similare din punct de vedere al 
funcţionalităţii. Versiunile noi ale aplicaţiei, îmbogăţite funcţional, nu 
trebuie să modifice maniera de lucru anterior adoptată. 

consistenţa cu mediul de operare - menţinerea unui grad ridicat de 
consistenţă cu convențiile de interacţiune şi interfaţă furnizate de 
sistemul de operare va asigura exploatarea mai facilă a aplicaţiei, 
utilizatorul fiind deja familiarizat cu acestea. Orice nouă aplicaţie 
destinată unui sistem de operare trebuie să se alinieze la standardele pe 
care acesta le impune, iar efectul acestei constrângeri nu poate fi decât 
benefic, facilitând însuşirea mai rapidă a noului produs. 

consistenţa cu metaforele utilizate. Se recomandă menţinerea 
metaforelor cu care utilizatorul este deja familiarizat şi alegerea cu grijă a 


metaforelor noi. Adesea, dacă un comportament particular nu poate fi 
asociat unui obiect aşa cum reiese din metafora definită, utilizatorul are 
dificultăţi în realizarea unei asocieri între comportament şi obiect. 

Prin respectarea acestui principiu se obţine ceea se numeşte stabilitate - 
interfaţa este familiară (chiar dacă e vorba de o aplicaţie nouă), iar răspunsul 
aplicaţiei este previzibil (se mizează pe comportamentul similar al aplicaţiilor). 

Toleranţa la erori 

Toleranţa este necesară datorită comportamentului utilizatorilor, care sunt în 
definitiv simpli oameni, supuşi greşelilor. Cel mai la îndemână exemplu este 
ştergerea unui fişier, efectuată din greşeală, fiind grăbiţi, obosiţi sau neatenţi. O 
astfel de eroare are un impact puternic asupra moralului utilizatorului, mai ales 
când nu există o modalitate de recuperare sau aceasta este dificil de identificat. 
Impunerea acestui principiu pleacă deci de la premiza că utilizatorul obişnuit face 
frecvent greşeli, atât fizice (cum ar fi apăsarea accidentală a unei taste), cât şi de 
logică. O interfaţă bine proiectată trebuie să înţeleagă gama de erori potenţiale pe 
care utilizatorui poate să le comită şi să aibă prevăzute posibilităţi de ieşire din 
astfel de situaţii şi de recuperare a eventualelor pierderi. 

Un alt aspect deosebit de important în cadrul acestui principiu se referă la 
maniera de atenţionare a utilizatorului asupra apariţiei unei erori sau asupra riscului 
unei anumite operaţii. Mesajele furnizate în această situaţie trebuie să descrie 
succint şi concis problema, astfel încât utilizatorul să înţeleagă sursa erorii sau riscul 
la care se poate aştepta în cazul continuării unei peraţii (de obicei este vorba de 
operaţiile de ştergere şi modificare a datelor preluate deja la nivelul aplicaţiei) 

Spre exemplu, să discutăm despre butoanele predefinite sau combinaţiile de taste 
pentru anumite comenzi(cunoscute sub numele de „shortcut”). De regulă, fiecare 
ecran sau casetă de dialog are un buton de comandă predefinit, care este invocat 
atunci când utilizatorul apasă tasta Enter şi pentru fiecare buton de acţiune există 
şi o combinaţie de taste ce poate fi utilizată în lolocul mouse-ului. Riscul este ca 
utilizatorul să apese involuntar tasta Enter, lansând astfel comanda ataşată 
butonului implicit, sau o combinaţie de taste validă care dfeclanşează comanda 
asociată unui anumit buton. În aceste cazuri este esenţial un mesaj de avertizare 
(în special pentru operaţiile distructive). 

În plus, utilizatorii sunt adesea tentaţi să exploreze o interfaţă, prin 
selectarea "oarbă" şi "la întâmplare" a comenzilor şi opţiunilor unei aplicaţii, în 
acest fel utilizatorii îşi însuşesc modul de exploatare al unei aplicaţii - este metoda 
numită "încercare şi eroare" sau învăţarea prin descoperire. O interfaţă bine 
proiectată permite descoperirea interactivă a modului de exploatare a! unei 
aplicaţii. Prevenirea distrugerii datelor sau a blocării sistemului trebuie asigurată 


prin mesaje de avertizare în situaţiile în care starea aplicaţiei sau datele cu care 
operează aceasta se pot deteriora şi prin reversibilitatea unor acţiuni (posibilităţi de 
anulare sau de recuperare a datelor ) 

Dacă la un moment dat, într-un anume context, o opţiune sau un submeniu nu se 
pot utiliza, cel mai bine este să indicăm cumva indisponibilitatea, într-un mod 
distinct faţă de opţiunile disponibile (printr-o proprietate de tip Grayeg, care lasă 
opţiunea vizibilă, dar nu permite selectarea ei) şi nu să le ascundem. Ascunderea 
componentelor îl poate bulversa pe utilizator, care încearcă să-şi construiască un 
model menta! al funcţionării aplicaţiei. 

Asocierea de "replici" pentru comenzile unei aplicaţii 

Conform acestui principiu, o interfaţă este bine să transmită câte o replică sau un 
răspuns pentru fiecare acţiune a utilizatorului. Această cerinţă contribuie şi ea la 
sporirea confortului utilizatorului şi ea impune ca aplicaţia să confirme (prin replici) 
că a preluat cererea utilizatorului şi că este în curs execuţia acţiunii aferente cererii. 
Replicile pot fi vizuale sau auditive şi trebuie să confirme utilizatorului că aplicaţia 
răspunde într-adevăr la acţiunile sale. Aceste replici trebuie să apară în timp real, 
adică concomitent cu desfăşurarea operaţiei cerute. Puţini utilizatori (în fapt, cei 
avizaţi şi experimentați) rămân indiferenți în faţa unui ecran care nu afişează nici 
un mesaj şi care nu reacţionează în nici un fel dacă prelucrarea ce se execută la 
momentul respectiv durează ceva mai mult timp. Când este vorba de acţiuni de 
durată mai mare, replica ce trebuie afişată trebuie să precizeze: starea (derularea) 
acţiunii în curs (de obicei cu exprimare în procente sau în secunde ce au rămas), 
precum şi modul în care acţiunea poate fi suspendată sau anulată. Există două 
posibilităţi de informare a utilizatorului asupra acţiunii pe care aplicaţia o execută la 
un moment dat: 

- prin actualizarea liniei de stare (linia care apare în partea inferioară a 
ferestrei principale); 
- prin afişarea de casete de mesaj. 

Atunci când informaţia ce trebuie afişată este redusă ca dimensiuni, linia de stare 
a aplicaţiei este suficientă pentru afişarea de mesaje. Dacă însă este nevoie de 
afişarea unui mesaj mai amplu şi dacă particularităţile acţiunii în curs permit 
întreruperea şi/sau abandonarea acesteia, atunci se recomandă să se recurgă la o 
casetă de dialog non-modală care să cuprindă atât informaţiile, cât şi butoanele 
corespunzătoare acţiunilor de întrerupere sau terminare a acţiunii în curs. 

© Estetica 

Principiul acesta se referă la proiectarea elementelor vizuale. Interfața trebuie 
să atragă utilizatorul; un mediu de lucru plăcut, prietenos contribuie la confortul 
utilizatorului şi la o mai bună înţelegere a informaţiei prezentate. Atributele 


vizuale furnizează date preţioase şi comunică informaţii importante cu privire la 
comportamentul diferitelor obiecte. O recomandare care decurge din aplicarea 
acestui principiu este implicarea utilizatorului în proiectarea interfeţei. De multe ori, 
lucruri care par evidente pentru proiectant sunt pentru utilizatorul de rând neclare 
sau ambigue. 

Următoarele aspecte detaliază principiul esteticii: 

- utilizarea corespunzătoare a culorilor. Un prim aspect se referă la 
folosirea aceleaşi scheme de culori în toate ecranele aplicaţiei. Apoi, 
trebuie respectată regula contrastului (culoare închisă pe fond deschis sau 
culoare deschisă pe fond închis), astfel încât ecranele să fie citibile. O 
combinaţie roşu-albastru este foarte frumoasă, dar absenţa contrastului 
poate crea probleme de urmărire a textului pe ecran. In fine, se alege 
uneori o anume culoare pentru a scoate în evidenţă o opţiune sau o 
situaţie deosebită, întrucât nu toţi utilizatorii reacţionează la culori, se 
recomandă folosirea şi a unui indicator secundar (un simbol deosebit sau un 
semnal sonor). 

- folosirea de fonturi adecvate - este vorba aici de fonturi uşor de citit 
(spre xemplu, Times New Roman în loc de Comic Sans MS). De asemenea, 
atenţie la numărul de fonturi ce se folosesc pe acelaşi ecran - în nici un 
caz mai mult de trei. Se pot obţine efecte diferite prin folosirea de 
atribute (bold, italic, umbrit) pentru acelaşi font. 

- alinierea câmpurilor şi datelor propriu-zise. Datele se aliniază 
corespunzător tipului lor astfel: şirurile la stânga, datele numerice întregi la 
dreapta, iar cele numerice reale se aliniază după marca zecimală, datele 
calendaristice tot la dreapta. 

Claritatea 

Principiul clarităţii poate fi discutat din 3 puncte de vedere: vizual, 
conceptual, lingvistic. 

Claritatea vizuală este asigurată de elementele vizuale (obiectele) care o 
compun. Acestea trebuie să fie sugestive, uşor de înțeles, ele reprezentând în fapt o 
transpunere simplificată a unor obiecte reale. De asemenea, este importantă şi 
aranjarea obiectelor pe ecran. Opțiunile sau comenzile care se grupează din punct 
de vedere logic trebuie reunite şi delimitate de celelalte prin chenare sau cadre, în 
mod simiiar, trebuie plasate separat şi delimitate între ele opţiunile între care nu 
există legătură. 

Claritatea conceptuală se caracterizează prin două atribute: simplu şi realist' 
Simplitatea interfeței înseamnă afişarea unui număr rezonabil de obiecte pe ecran 
(într-o fereastră), iar caracterul realist este asigurat prin similitudinea cu obiectele 


reale (de exemplu, dacă o fereastră prezintă o factură, este de dorit ca obiectele 
care o descriu să reproducă cât se poate de exact aspectul acesteia). 

Claritatea lingvistică se referă la textul ce apare în interfaţă. Denumirile 
opţiunilor de meniu, mesajele, opţiunile, etc. trebuie să fie clare, neambigue. 
Textul pe care îl afişăm pe ecran este o sursă principală de informare a utilizatorilor, 
de aceea ar trebui să se utilizeze cuvinte sau propoziţii întregi, nu prescurtări. Mesajele 
trebuie să fie formulate categoric şi fără ambiguităţi. Spre exemplu, la operaţiunea de 
introducere a codului clientului, dintre următoarele două mesaje "Lungimea codului de 
client este de 5 caractere!", "Aţi introdus o valoare eronată!" ar trebui utilizat primul, 
altfel utilizatorul va fi derutat, pentru că nu are cum să intuiască ce anume se doreşte 
de la el. 

Simplitate 

O interfaţă trebuie să fie simplă, uşor de învăţat şi exploatat. Ea trebuie să 
permită accesul facil la toate funcţionalităţile oferite de aplicaţie. Este recomandată 
reducerea informaţiilor prezentate în interfaţă la strictul necesar unei comunicări 
eficiente (trebuie evitate descrierile detaliate, frazele stufoase sau irelevante). 
Importantă este şi aranjarea şi prezentarea elementelor interfeţei (se vor folosi 
semantici şi ordini de reprezentare naturale). 

Maximizarea funcţionalităţii unei aplicaţii intră în contradicţie cu simplitatea 
cerută, dar cele două aspecte pot fi echilibrate printr-o proiectare corespunzătoare. 

O metodă recomandată, mai ales pentru aplicaţiile cu grad mare de 
complexitate, este metoda descoperirii progresive. Această metodă se bazează pe 
două aspecte: 

- organizarea atentă a informaţiilor, evitând aglomerarea pe un singur ecran; 

- prezentarea fiecărei informaţii la momentul potrivit - atunci când nu 
este nevoie de ea, informaţia se ascunde. “"Ascunderea" datelor reduce 
cantitatea de informaţii cu care utilizatorul vine în contact la un moment 
dat. 

Deci, o interfaţă bună va prezenta informaţia într-o manieră ierarhică. De 
exemplu, informaţia de control (comenzile disponibile ale aplicaţiei) se înglobează, 
de obicei, în meniuri, în funcţie de contextul de utilizare, o parte din opţiunile unui 
meniu, indisponibile la un moment dat, se pot ascunde sau inhiba, în plus, este 
posibilă introducerea unor instrumente de lucru suplimentare. Un exemplu este 
linia de intsrumente (toolbar-ui), care reuneşte comenzile de meniu mai frecvent 
folosite sub formă de butoane, tocmai în ideea ca accesarea acestor comenzi să se 
facă cât mai simplu. 


4.1.2. Ciclul de dezvoltare a unei interfeţe grafice utilizator 


Dezvoltarea unei GUI se bazează pe un ciclu iterativ, care cuprinde 4 faze: 
- determinarea cerinţelor; 
- construirea prototipului; 
- evaluarea prototipului, prin implicarea utilizatorului; 
- finalizarea. 

Din punct de vedere conceptual aceste faze sunt identice cu etapele de 
dezvoltare ale unei aplicaţii, cu menţiunea că fiecare fază are caracteristici şi 
elemente suplimentare specifice. 

Construirea prototipului porneşte de la cerinţele identificate în faza 
anterioară şi are în vedere transpunerea acestora într-un model concret. Se 
utilizează un instrument de prototipizare sau un limbaj de nivel înalt pentru a 
construi ecranele, dialogurile şi rapoartele ce vor constitui interfaţa aplicaţiei. Cel 
mai bun sfat pentru această etapă este să nu se acorde prea mare importanţă 
dezvoltării codului pentru implementarea comportamentului interfeţei, întrucât 
există şanse mari să apară modificări ale prototipului (cel puţin în primele variante) 
în faza de evaluare. 

Cei mai frecvent se utilizează bibliotecile de clase: fiecare element al GUI este 
definit ca o clasă, din care se va crea o instanţă în aplicaţia proiectată. 

Observaţie: dezvoltarea de prototipuri nu înlocuieşte diagramele de flux, cele 
două instrumente ar trebui utilizate în mod complementar. 

Experienţa recomandă construirea a trei tipuri succesive de prototipuri: un 
prototip făcut "de mână", care include doar funcţionalităţile de bază 
(fundamentale), apoi un prototip electronic, în care se transpun de asemenea doar 
funcţionalităţile de bază şi la urrnă un prototip electronic complet al interfeţei. 
Această metodă graduală de construire a prototipurilor s-a dovedit eficientă sub 
aspectul timpului consumat pentru această activitate, în plus, creşterea treptată a 
complexităţii pe măsura apropierii de soluţia finală îl ajută pe utilizator să înţeleagă 
cum va lucra de fapt aplicaţia proiectată. 

Evaluarea prototipului verifică dacă ceea ce propune echipa de proiectare 
(prototipul construit) corespunde cu ceea ce aşteaptă utilizatorii. Evaluarea 
răspunde de regulă ia 3 întrebări: ce este bun la prototip, ce nu este bun şi ce 
lipseşte prototipului. După evaluare se constată adesea că e nevoie să se renunţe la 
unele elemente, că trebuie adăugate componente noi, iar altele existente trebuie 
modificate. 


În această fază trebuie implicaţi activ utilizatorii produsului final sau - dacă e 
vorba de o aplicaţie destinată unei mase largi de utilizatori, evaluarea trebuie să o 
facă persoane care au caracteristicile celor cărora le este destinat produsul (în nici 
un caz evaluarea nu o vor face proiectanţii, pentru că intervine diferenţa de cultură 
şi experienţă şi, în plus, există riscul pierderii obiectivităţii în apreciere). 

Nemulţumirile şi obiecțiile celor care evaluează prototipul generează un ciclu 
iterativ care cuprinde fazele 2 şi 3. Acest ciclu de rafinare se repetă până când nu 
mai apar obiecţii sau cerinţe noi (sau cerinţele noi formulate sunt nesemnificative, 
de importanţă redusă). 

De-a lungul acestui proces iterativ, pe măsură ce prototipul sau componente 
ale acestuia primesc acceptul utilizatorilor, se trece la înlocuirea lor cu aplicaţia 
propriu-zisă. Trebuie evitate întârzierile ce pot apare de-a lungul ciclului de 
dezvoltare datorită scrierii programelor, înlocuirea prototipului cu aplicaţia trebuie 
să se facă în momentul în care nu mai pot apare schimbări semnificative în cadrul 
proiectului. 

Pe scurt, următoarele aspecte trebuie respectate pentru o prototipizare 
eficientă: 

- cerințele utilizatorului trebuie să fie punctul de plecare în elaborarea 
prototipului; 

- înţelegerea problemei căreia i se adresează aplicaţia (prin discuţii cu 
utilizatorii cheie, documentare la faţa locului sau folosind documentaţia 
Internă existentă) - cu cât se va înţelege mai bine problema, cu atât 
interfaţa aplicaţiei va fi mai bună; 

- în faza de evaluare trebuie să se identifice: ce este bun la prototip, ce este 
rău la prototip, ce îi lipseşte; 

- se va opri prototipizarea atunci când evaluarea generează doar obiecţii 
minore; 

- folosirea, pe cât posibil, de obiecte din lumea reală - se vor exploata în 
acest fel cunoştinţele anterioare ale utilizatorului (asta presupune 
identificarea obiectelor reale care se potrivesc şi cunoaşterea modului în 
care oamenii interacționează cu ele); 

- planificarea timpului şi respectarea termenelor stabilite; 

- seva cere utilizatorilor finali să testeze şi să evalueze prototipul 
(implicarea acestora în faza de prototipizare are beneficii evidente); 

- nu se va investi prea mult timp în componente la care utilizatorii ar 
putea renunţa şi în scrierea de cod, întrucât acesta sigur va suferi 
modificări după evaluare; 


- pentru fiecare obiect din interfaţă se vor include în documentaţie: scopul şi 
modul său de utilizare, legăturile sale cu celelalte obiecte din interfaţă şi - 
dacă e cazul - scopul şi modul de utilizare a! componentelor sale. 

Documentarea fiecărui obiect se face doar după definitivarea sa în cadrul etapei de 
evaluare. 


4.1.3. Programarea bazată pe evenimente 


In programarea procedurală tradiţională, procesul de calcul este in intregime 
ghidat de instructiunile programului. Imediat ce s-a incheiat executarea unei 
instructiuni, se trece la instructiunea urmatoare, respectand fluxul programului 
respectiv. Aceasta se refera şi la interactiunea dintre program si utilizator. Chiar 
dacă programul este interactiv, initiaţiva privind datele ce trebuie introduse si in ce 
moment se introduc acestea aparţine programului. Operatorului uman nu îi ramane 
decat sa se conformeze solicitărilor acestuia şi să introducă date atunci cand ele 
sunt cerute de program. Este evident ca un asemenea rol nu este deloc convenabil 
pentru utilizator, care de cele mai multe ori doreşte să deţină controlul şi să fie el 
cel care ia iniţiativa acţiunilor. 

Apariţia interfeţelor grafice a permis introducerea unei noi concepţii in 
interactiunea dintre operator si aplicaţie, astfel că iniţiativa să îi revina operatorului 
uman, iar programul să execute comenzile acestuia. S-a trecut astfel de la 
programarea procedurala traditionala la programarea orientata pe evenimente 
(engleza: Event-Oriented Programming), cunoscuta şi sub numele de programare 
ghidata de evenimente (engleza: Event Driven Programming). 

Se numeşte eveniment orice modificare care are loc fie in starea dispozitivelor de 
intrare, fie in cea a obiectelor grafice de pe ecran: apasarea sau eliberarea unei 
taste, deplasarea mouse-ului, apasarea sau eliberarea unui buton al mouse-ului, 
deschiderea sau inchiderea unei ferestre, efectuarea unui clic de mouse pe un 
obiect de control (buton, caseta de validare, bara de defilare etc. ), intrarea 
cursorului mouse-ului în campul activ al unui obiect grafic sau părăsirea acestuia 
etc. Trebuie menţionat că pot exista şi alte tipuri de evenimente, fără legătură cu 
interfaţa grafică (vezi noţiunea de declanşator (trigger) pentru baze de date), dar 
aici ne intereseaza numai cele legate de interfaţa grafică a aplicaţiei. 

In programarea orientata pe evenimente, iniţiativa aparţine operatorului uman: 
acesta acţioneaza asupra dispozitivelor de intrare (tastatura, mouse si altele), 
generand astfel evenimente la care trebuie sa raspundă programul. 

Interactiunea dintre operator si aplicatie intr-un sistem bazat pe evenimente 
decurge astffel: 


e operatorul provoaca generarea unui eveniment, acţionand asupra 
tastaturii, mouse-ului sau a altui dispozitiv de intrare. In cazul tastaturii, 
evenimentul este generat prin apasarea sau eliberarea oricarei taste. In 
cazul mouse-ului generarea se face fie direct de catre acesta, ca urmare a 
deplasarii mouse-ului sau apasarii /eliberarii unui buton, fie de catre un 
obiect grafic de pe ecran, ca urmare a interacțiunii dintre acesta şi cursorul 
de mouse. 

e Evenimentul, astfel generat, poate declanşa execuţia unui modul de 
program, care defineşte o acţiune specifică în funcţie de tipul de 
eveniment şi obiectul grafic pentru care a fost declanşat. 

Problema care se pune în acest caz constă în identificarea modului de construire 
a unui program astfel încât el să reacționeze la evenimente. Arhitectura sistemului 
de operare Windows este destul de complicată şi nu ne vom ocupa aici de 
explicarea modului cum se nasc evenimentele; e suficient să ştim care sunt acestea 
şi că mediile de dezvoltare oferă mecanisme pentru captarea şi interpretarea 
acestor evenimente. În varianta Visual Basic şi a produselor similare, o aplicaţie 
constă dintr-un ansamblu de subrutine ce implementeaza logica aplicatiei 

Şi subrutine (proceduri sau subprograme) numite proceduri-eveniment şi care 
tratează un eveniment individual. O astfel de procedură este ataşată unui control şi 
se execută numai atunci construită conform notaţiei ungureşti: optAscendent, 
optDescendent, optNeso 


Clasa Recordset. Tehnici specifice de manipulare a datelor. 

După cum s-a văzut şi în exemplul anterior, un obiect Recordset nu este altceva 
decât reprezentarea obiectuală, la nivelul aplicaţiei client, a unui set de date 
(înregistrări) extrase ca urmare a execuţiei unei fraze Select-SQL. În termeni uzuali, 
un obiect Recodset are la bază un cursor, generat de driver. Un cursor prezintă 
datele într-o manieră familiară (linii şi coloane) indiferent de modul de reprezentare 
fizică a acestora la nivelul sursei de date şi oferă diverse modalităţi de manipulare a 
acestora astfel: 

e Pentru un cursor există noţiunea de pointer de linie, sau linie curentă. 
Astfel, la un moment dat putem extrage/modifica datele ce constituie linia 
respectivă 

e Există posibilitatea deplasării de la o linie la alta, înainte şi înapoi 

Un cursor se crează automat la execuţia metodei open() a unui obiect 
Recordset. Semnătura acestei metode este următoarea: 


objRecSet.Open(Source, ActiveConnection, CursorType, LockType) 
unde: 
- Source - va reprezenta comanda Select SQL ce va fi executată la nivelul 
sursei de date (furnizată sub formă de şir de caractere: String) 
-  ActiveConnection - obiectul de tip Connection ce furnizează conexiunea 
fizică la sursa de date. Acest obiect trebuie să furnizeze o conexiune 
activă, în sensul că trebuie să-i fi fost invocată metoda open() înainte de a-l 
trimite acestui parametru (vezi şi exemplul din listingul 4-2). 
Ultimii 2 parametri sunt opționali (dar esentiali) şi necesită câteva lămuriri 
suplimentare. 
Există mai multe tipuri de cursoare: 
-  Cursoare care permit, sau nu, actualizarea datelor 
-  Cursoare care permit deplasarea de la o linie la alta înainte şi înapoi, şi 
cursoare care permit deplasarea doar într-un singur sens (înainte), o 
singură dată 
- Cursoare dinamice şi statice.  Cursoarele dinamice sesizează 
actualizările(insert, update, delete) efectuate de alţi utilizatori asupra sursei 
de date, aceste actualizări devenind imediat disponibile utilizatorului 
cursorului. Cursoarele statice reprezintă o imagine a sursei de date la un 
moment dat în timp (la momentul execuţiei frazei Select-SQL), actualizările 
efectuate de alţi utilizatori fiind disponibile doar prin reinterogarea sursei de 
date. 
După cum se poate intui, tipul cursorului depinde de necesităţile aplicaţiei şi va fi 
stabilit de către programator prin intermediul celui de-al treilea parametru 
(CursorType) la invocarea 


